The Arsenal Files 1/The Arsenal Files (Arsenal Computer).ISO/bbs/tm0305.txt

Text File | 1994-01-23 | 31KB | 610 lines

SEA Technical Memorandum #0305, Adding GroupMail to a Bink/Confmail System
Contributed by: Jack Decker
Last updated: March 7, 1989
Copyright 1989 by System Enhancement Associates, Inc.



             Adding GroupMail to a Binkleyterm/Confmail System


This document is an attempt to give you some solid information on how to
implement GroupMail on a system that is already successfully running
BinkleyTerm and confmail.

This information is going to be presented more or less in "cookbook"
format.  I am going to make a few assumptions to start with... that you are
not a "top star" for any conference, that you're not going to feed
GroupMail conferences to any non-MSDOS systems that can't run the GroupMail
software, and that you're not going to try and convert any GroupMail
conference to Echomail or vise-versa.  If any of these assumptions don't
apply to you, read on anyway, I'll cover one of the exceptions later, and
the rest of the information will still be useful to you.

This is NOT a substitute for the GroupMail documentation.  Read it, too!
Also, please count on this information containing at least one glaring
error and at least a couple of things that could have been done more easily
in some other way.  I don't claim to be perfect.  But I would like to know
of any errors that you do find.

Here are the changes you will need to make to your system:

 1) CONFIG.SYS - Group requires some new environment variables to be set.
    If you haven't already done so, you can reserve extra space for
    environment variables by inserting the following line into your
    CONFIG.SYS file:

         shell=command.com /p /e:512

 2) AUTOEXEC.BAT - Here is where you add a new line to set a new
    environment variable that will be used by GroupMail:

         SET SEADOG=C:\OPUS

The SEADOG variable should point to the directory that you normally run
BinkleyTerm from.

 3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc.  Here are
    the changes you need to make:

    a) If you test for the existence of mail bundles in your net files area
       before running ConfMail Import, either delete these tests (you don't
       really need them anyway) or add tests for the GroupMail bundles you
       expect to receive.  GroupMail bundles are named with the area name
       (up to eight characters) plus an unpredictable three-character
       extension.  So, for example, if you are expecting to receive
       GroupMail bundles for the COOKING area, you could test for files
       named COOKING.* (or COOKING.???) in your net files area.  I again
       emphasize that such tests are normally not necessary, but some
       people like to use them to shave a few seconds off of batch file
       processing time.

    b) your line that calls ConfMail Import should *NOT* include the -M
       option, but *SHOULD* include the -K option.  I use the following
       line:

            confmail import areas.bbs -K -N -F confmail.out

       Now a bit of explanation... if you really want to use the -M option,
       you can probably do so as long as you are not converting any
       GroupMail bundles to echomail prior to passing them downstream.  I
       suggest removing the -M option now (if you have been using it)
       because sooner or later you may wish to convert a GroupMail
       conference to echomail, and it won't work if -M is set.

       The -K option will automatically kill all the null file attach
       messages that your GroupMail feed generates.  If you don't mind
       skipping through all the null file attach messages when you read
       your netmail (you WILL mind eventually), leave out the -K.

    c) You should place the following line immediately AFTER your call to
       ConfMail Import, BEFORE you do anything else:

            GROUP IN /L

       This does two things... first, it unpacks any GroupMail bundles you
       may have received, and second, it scans your netmail area for any
       GroupMail messages that need to be readdressed to your uplink.  That
       is why it needs to be run AFTER ConfMail Import... if you run it
       BEFORE ConfMail Import, any messages you've received from your
       downstream nodes may not get properly forwarded to the Top Star via
       your GroupMail feeds.  And you need to run Group In BEFORE running
       ReMapper, oMMM, or any other program that may change the headers of
       those messages.  So play it safe, and run Group In right AFTER
       ConfMail Import.

       By the way, the /L tells GROUP to relink the message threads.  It
       does basically the same thing for GroupMail conferences that
       ReplyLnk (or ConfMail Maint in older versions of ConfMail) does for
       your echomail conferences.

    d) Just prior to calling oMMM, you should place the following line:

            GROUP OUT

       This will check all your GroupMail areas for new messages, and send
       out anything you have waiting.

    Now, if you have read the GroupMail documentation, you may be a little
    confused at this point, since the docs tell you to run GROUP on certain
    schedules (GROUP OUT in the evening before your mail hours, and GROUP
    IN in the morning after all mail has been received).  But keep in mind
    that the folks writing the documentation are using SEADOG, which runs
    on schedules.  You probably aren't running schedules in that way.  If
    by chance you do run ConfMail Import only at certain specified times,
    just do GROUP IN immediately afterward.  But, if like most of us, you
    run ConfMail Import every time mail is received, you should run GROUP
    IN immediately afterward.  If you then do a ConfMail Export, you should
    run GROUP OUT prior to calling oMMM.  GROUP runs very fast (faster than
    ConfMail when tossing messages, in my opinion) so you needn't worry
    about it consuming an inordinate amount of time while executing on your
    system.

 4) AREAS.BBS - There are two important considerations here.  First, if you
    are using a BAD_MSGS area, GET RID OF IT NOW!!!!  This is *EXTREMELY*
    important.  If you don't do this, some or all of the GroupMail messages
    originating on your system (or on systems that you feed) will be tossed
    to the BAD_MSGS area by ConfMail, and will never leave your system.
    Second, make sure you don't have any echo area names that duplicate
    GroupMail areas, for the same reason (ConfMail will toss any messages
    that are supposed to go to your uplinks to those areas instead.  The
    exception to this is if you're converting a GroupMail conference to
    Echomail, but right now we're assuming you aren't doing that,
    remember?).

    Of course, someone will say that if you are VERY careful about how you
    write your batch file, you can get around these problems.  That may be
    true (although I have my doubts!), but in any event I don't feel like
    giving a short course in writing batch files here.  I'm simply taking
    the safe road by saying "don't do these things."

 5) CONFIG.DOG - You need one of these, even though the GroupMail
    documentation says that a Mail.Sys file will do (it won't, at least not
    with GroupMail versions through 2.04).  Fortunately, a Config.Dog file
    is simple to make... you just use any text editor.  Mine looks like
    this:

         name Jack Decker
         node 1:154/8
         aka 77:1011/8
         aka 8:70/8
         mail C:\MSG\NET
         files C:\FILE\NET

    "Name" is the name of the Sysop, "Node" is your primary address, "Aka"
    lines contain any other addresses you use (in the same net or in other
    nets), "Mail" is the path to your netmail area, and "Files" is the path
    to your incoming net files area (which is what GROUP can't find if you
    only have a Mail.Sys file).

 6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your system).  Be
    sure to put a poll statement in for each system you pick up GroupMail
    from (unless you are using some other method for doing polls, or your
    feed is calling you).

 7) DELIVER.GRP - You need this file if you are feeding GroupMail to any
    other BinkleyTerm systems, or any other system that can't generate File
    Update Requests.  Note that future versions of BinkleyTerm will
    supposedly include the capability to do File Update Requests, but
    present versions of Binkley do not.  DELIVER.GRP is simply a list of
    systems that are to receive any given GroupMail area from you.  I quote
    from SEA Technical Memorandum #0302:

    "The GroupMail conferencing system is, by design, a pickup system
    instead of a delivery system.  If at all possible, it should be used as
    such, because that is how GroupMail avoids the bulk of the technical
    problems with echomail.

    "However, at least one popular network mailer is not capable of
    properly negotiating a file update request, which is the mechanism by
    which GroupMail functions.  Until that can be rectified, GROUP requires
    some sort of delivery mechanism in order to link such systems into
    GroupMail.

    "If a file named 'DELIVER.GRP' is placed in the SEAdog directory, then
    GROUP 2.03 will use it as a delivery list, and create file attach
    messages for each new GroupMail archive as it is posted by GROUP PACK
    (for a top star) or GROUP IN (by a middle star).  The format of the
    DELIVER.GRP file will look very familiar to those acquainted with
    echomail.

    "The DELIVER.GRP file is a normal ASCII text file.  Each line begins
    with the name of a group conference, with the remainder of the line
    being a list of network addresses to which it should be delivered.  A
    conference may be listed more than once, in which case it is addative.

    "For example, a possible DELIVER.GRP file might be:

        BLATZ 520/1015 107/528
        GNORF 107/528


    "By adding support of a delivery mechanism, we open the door to all the
    troubles echomail is heir to.  However, the door is open only a tiny
    crack at this time.  The single biggest problem with a delivery system
    is that of faulty topologies that cause duplicate messages.  This is
    largely avoided from the start because all duplicate GroupMail archives
    have the same name.  The remaining opportunities for duplicate messages
    to be generated are avoided because GROUP 2.03 refrains from unpacking
    any GroupMail archive that is older than the 'update marker' for that
    conference."

    [end quote]

    Two notes about DELIVER.GRP... first, you DON'T put the node number of
    YOUR feed in it, only of those systems that are fed BY YOU (this
    differs from an AREAS.BBS file, which must contain the node number of
    your feed and of those system that you feed).  Second, if you aren't
    feeding a particular GroupMail conference to anyone else, it doesn't
    have to be listed at all.

 8) OKFILE.LST - Your "requestable files" list for BinkleyTerm.  Add the
    following line:

         C:\GRPHOLD\*.*

    (or whatever path you specified for your GRPHOLD directory in the SET
    command in AUTOEXEC.BAT).  I'm assuming that you already have such a
    list.  If not, you'll also need to uncomment the following line in your
    Binkley.Cfg file:

         Okfile     c:\opus\okfile.lst

    (of course you should change the path if the subdirectory you're
    running Binkley out of is not called OPUS).

    This should allow other systems to obtain any GroupMail areas that you
    carry on your system.

 9) \GROUP\ORIGIN - A file called "Origin" that sits in your GROUP
    directory.  For starters, this can be the same as the first line of
    your "AREAS.BBS" file up to the exclamation point.  You can use custom
    origin lines for individual conferences by creating a file called
    "Origin" in individual Group areas, in the same manner in which you
    create custom origin lines for individual message areas using ConfMail.
    See the GroupMail documentation for more information.

10) System files.  You'll need to provide your BBS program and/or message
    reader/editor with the paths to your GroupMail areas.  Ditto with your
    message cleanup routine (that calls RENUM or some other message
    renumberer).  This will vary from system to system, but should not be
    too difficult to figure out.

11) GROUP.EXE - The central program of GroupMail, and the one that does
    most of the work for you.  If you've set up echomail conferences in the
    past, you'll appreciate the ease with which GROUP takes care of many of
    the little details of adding or deleting conferences for you.  For
    example, it creates all necessary subdirectories for you, creates and
    maintains the AREAS.DOG file for you, etc.



Now, if you are not a Top Star, you can basically get by using only three
basic GroupMail commands (quoted from the GroupMail documentation):

GROUP ADD <conference> <description> ;<uplink>

     This is the command you use to add a new conference.  Suppose, for
     example, that you would like to get the BLATZ conference from 520/542.
     You would type:

         GROUP ADD BLATZ Gzorniblatz forum ;520/542

     GROUP will take care of the details, like creating the proper
     directories and updating your AREAS.DOG file.  If you run a BBS and
     you want the conference to be available on your system you will need
     to add the directory to your message areas.  The message directory
     that GROUP creates will (by default, see later) be a subdirectory of
     the GROUP subdirectory, or in this case it would be "GROUP\BLATZ".

     If you are running a mailer other than SEAdog, then you may need to
     add the directory to your areas list also.  In any event, DO NOT
     delete the AREAS.DOG file, as that is used by GROUP to keep track of
     your conferences.

     If you want to import GroupMail into a BBS that uses a different
     message base format, you'll need to do a bit more work.  See the
     section on this below.

[You might imply from the above that you should add GroupMail areas to your
AREAS.BBS file.  That is NOT the case, however, unless you are converting a
GroupMail conference to echomail, which we're assuming that you're not
doing right now!]


GROUP DEL <conference> . . .

     This is used to remove one or more conferences.  For example, if you
     wanted to remove the BLATZ conference you would type:

         GROUP DEL BLATZ

     If you wanted to remove both the BLATZ conference and the GNORF
     conference, you would type:

         GROUP DEL BLATZ GNORF

     Again, GROUP will take care of the housekeeping details, such as
     deleting any messages and removing the subdirectory.



GROUP EDIT <conference> <description> ;<uplink>

     This is used to change an existing conference.  For example, if you
     wanted to change your uplink on the BLATZ conference to 440/1, you
     would type:

         GROUP EDIT BLATZ Gzorniblatz forum ;440/1

     As always, GROUP takes care of any housekeeping details.


[end of quoted material]

Since Binkley can't do File Update Requests, you do NOT use the GROUP ASK
command.  We've already covered the use of GROUP IN and GROUP OUT in the
batch file.  You don't use GROUP PACK unless you're a top star for a
conference.

There are several option switches that you can use to modify how GROUP
works, and most are described in the GROUP documentation.  The one that you
will probably want to use is the /R switch:

/R<x>  Retention;  This tells GROUP that any GroupMail archives that you
       are holding (if you are a star) should be deleted after <x> days
       (default is 30 days).  For example, you would use "/R5" to retain
       archives for five days.

For example, if you wanted to add the BLATZ conference with yourself as a
middle star retaining GroupMail archives for three days, you would type:

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3

Also, because Binkley cannot generate File Update Requests, you'll want to
use the /X switch when adding new conferences, as described in SEA
Technical Memorandum #0302:


/X   In ADD or EDIT only.  This switch indicates that the designated
     conference should not be requested.  The GROUP ASK command will not
     generate an update request for any conference that carries this
     switch.  This is intended mainly for use with conferences which are
     delivered or which are obtained via a GROUP GET (see above).

The bottom line is that when you add a new GroupMail conference, your GROUP
ADD line will most likely appear something like this:

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7

(assuming you want to retain conference archives for seven days in this
case).

If you are a leaf node (that is, you don't hold a particular conference for
anyone else to pick up), omit the asterisk and the /r7 in the above line.
In this case, the GroupMail bundle will be deleted after it has been
tossed.  The command line would then look like this:

    GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X

When you use the GROUP EDIT command, it should be in exactly the same
format as the GROUP ADD command.  In other words, if you are adding
switches, you must also re-enter all of the original switches.  The word
EDIT simply tells Group that you are modifying the particulars of an
existing conference, rather than creating a new one.


EXCEPTIONS AND SPECIAL CIRCUMSTANCES

The GroupMail manual tells you how to import GroupMail into non-compatible
message base formats (such as QuickBBS or TBBS).  In this case you use the
/N flag in your GROUP ADD statement.  Since most such systems don't use
ConfMail, this type of setup is a bit beyond our discussion.  I would only
caution you to be careful about the sequence in which you run you mail
import routine and GROUP IN.  You may have to run your import routine
twice... once to toss incoming mail, then GROUP IN to toss incoming
GroupMail bundles to the netmail area (and to readdress any GroupMail
messages destined for your uplinks), and once more to import any GroupMail
messages tossed to your netmail area by GROUP.  This is just guessing on my
part, since I don't have any actual experience with such systems.

However, a similar technique is used to convert GroupMail to Echomail.  You
might want to do this if you are receiving a GroupMail conference and want
to pass it on to another system that cannot run the GroupMail software.

Now, I would suggest that you DON'T do this unless absolutely necessary.
If it's just a case of one of the nodes you feed objecting to having to put
up the GroupMail software (although they are perfectly capable of doing
so), I would invite them to seek a feed elsewhere.  Converting a conference
from GroupMail to Echomail introduces several possible headaches, not the
least of which is that you could be the source of duplicate messages
entering the conference.

On the other hand, it's not something that's terribly difficult to do if
you have to.  SEA Technical Memorandum #0303 describes the process, but I
will give a couple of examples specifically for BinkleyTerm/ConfMail users.

The assumption here is that you are a middle star that is receiving the
conference in question as GroupMail, and feeding it to some other nodes as
GroupMail while feeding still other nodes as Echomail.

Your GROUP ADD line would be the same as usual, with the addition of the /N
switch.  For example:

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7

If you are not sending the conference to any other nodes AS GROUPMAIL, you
can omit the asterisk and the "/r7" switch.

Next, you ADD this area to your AREAS.BBS file, just like you would any
normal echo.  On your system, you will treat this conference as an echomail
area rather than a GroupMail area.  The /N option that you used in your
GROUP ADD statement causes GROUP to add an "AREA:" field and a "SEEN-BY:"
field listing the address of the uplink to any conference that you're
converting to echomail.

In your batch file, you will probably want to run ConfMail Import (WITH the
-M option), THEN Group In, and THEN a second run of ConfMail Import
(WITHOUT the -M option).  This will make sure that any GroupMail received
from your downstream nodes gets properly readdressed to your uplinks, and
that any Group conferences that GroupMail tosses to your netmail area get
properly tossed (by ConfMail) to the Echomail area you've set up for that
conference.  For example:

     confmail import areas.bbs -M -N -F confmail.out
     group in /L
     confmail import areas.bbs -K -N -F confmail.out

The only other items you have to worry about are how the area is defined in
your DELIVER.GRP and AREAS.BBS files.  As usual, your DELIVER.GRP file
should contain ONLY a list of nodes receiving the conference from you AS
GROUPMAIL.  Your AREAS.BBS entry for the conference in question should
contain a list of the nodes receiving the conference from you AS ECHOMAIL,
plus YOUR FEED of the conference.  The reason for including your feed is so
that any messages entered on your system, or sent to you by your downstream
links, will be exported to your upstream feed.

You may wonder what will happen to an echomail message sent upstream in
such a manner to your GroupMail feed.  If he is running that area strictly
as GroupMail, the message will be tossed into his netmail area (so long as
he does not have a BAD_MSGS area... this is why you CANNOT use a BAD_MSGS
area with GroupMail!!!), where (hopefully) GROUP IN will find it and
readdress it to his uplink, and so on.  If he is also operating the area as
both echomail and GroupMail, the message will get tossed into the echo area
on his system, and then exported to his upstream feed, and so on.

Anyway, that's all there is to it... BUT again I ask, "do you REALLY want
to convert echomail to GroupMail?"  If you are only feeding one or two
nodes that cannot accept GroupMail, there may be a better way:


SENDING GROUPMAIL TO NON-MSDOS SYSTEMS

The following information should be considered HIGHLY experimental.  If it
works for you, GREAT!  If it doesn't, well, you can always convert your
GroupMail conferences to echomail.

Let's say that you're feeding a point system that's running on a Commodore
Amiga (coincidentally, this is what Steve Palm, a point operator off of my
system is using).  He has a version of ConfMail and BinkleyTerm that's been
ported to the Amiga, as well as a message reader/editor, but there is no
way he can run the GroupMail software.

But, he is a leaf node.  That means he doesn't have to worry about
forwarding the conference to anyone else.  All he needs to be able to do is
to read the messages he receives, and send replies.

We already know (from the above discussion) that if he creates an echo area
with the same name as a GroupMail area on my system, and puts my node in
his AREAS.BBS list, that any messages he enters in that area will be
exported to my system, where GROUP IN will find them and readdress them to
my feed for the conference.  So as long as he can send me messages with the
proper AREA tag (which will be automatically affixed when ConfMail exports
the message from the echo area he's created), he will be able to enter
messages in a GroupMail conference.  So, if he can figure out some way to
process an incoming GroupMail bundle (so that he can read incoming
messages), I can just put his node in my DELIVER.GRP file and treat him
like any other GroupMail delivery point (which means I don't HAVE to
convert the GroupMail conference to Echomail!)

The question is, can he unpack a GroupMail bundle?  Well, it turns out that
there IS a way this can be done.  Once you extract a GroupMail packet from
its archive, the extracted mail packet has roughly the same format as an
Echomail packet, except that it's addressed to -1/0.  At least, it's close
enough that ConfMail will unpack and toss it if it thinks it's running on
node -1/0

So, in his CONFIG.DOG file, Steve inserts the address -1/0 as an AKA
address.  Then, in his batch file, he has to put a command to look for and
unARC any GroupMail bundles he might receive.  For example, if he's getting
COOKING and SHORTWAV from me, he'd put in the following lines (note these
are MS-DOS batch file lines for illustrative purposes only, not what Steve
is actually using on his Amiga):

     ARCE \FILE\NET\COOKING.*
     DEL \FILE\NET\COOKING.*
     ARCE \FILE\NET\SHORTWAV.*
     DEL \FILE\NET\SHORTWAV.*
     CONFMAIL IMPORT AREAS.BBS -N -A ARCE

ConfMail will find the bundles (addressed to -1/0, but the AKA takes care
of that) and unpack them.  Next... and this is important... he must do a
CONFMAIL EXPORT using an alternate AREAS.BBS format file that contains the
following:

     Origin Line ! Sysop Name
     \MSG\COOKING COOKING -1/0
     \MSG\SHORTWAV SHORTWAV -1/0

Why are we exporting to -1/0?  Well, since GroupMail uses that address, I
thought I would, too... actually, we could export to ANY phony node, but
the idea is to make ConfMail do an export operation on the newly-imported
GroupMail messages.  Why?  Well, keep in mind that GroupMail messages don't
have an origin or SEEN-BY lines.  Thus, if we simply allow them to be
rescanned in the normal manner, we've created an instant dupe loop, since
they will all get sent back to the source.  So, we do a "dummy" export
operation in order to reset the "high water mark" past the last new message
that we have just received in the area.  This may create an unwanted ".OUT"
file for -1/0, but we can always delete that as the next operation in the
batch file

So, the complete batch file segment would look something like this:

     ARCE \FILE\NET\COOKING.*
     DEL \FILE\NET\COOKING.*
     ARCE \FILE\NET\SHORTWAV.*
     DEL \FILE\NET\SHORTWAV.*
     CONFMAIL IMPORT AREAS.BBS -N -A ARCE
     CONFMAIL EXPORT ALTAREAS.BBS {options}
     DEL \OUTBOUND\FFFF0000.OUT

where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy -1/0 net/node
numbers, and FFFF0000.OUT is the name of the mail packet (for -1/0) created
by the dummy export operation.

Of course, when messages are entered using the message reader/editor, we
have to run ConfMail Export using the "real" AREAS.BBS file that contains
the same entries, but with the real net/node numbers for the GroupMail
feed(s) from which the conferences are received:

     Origin Line ! Sysop Name
     \MSG\COOKING COOKING 154/8
     \MSG\SHORTWAV SHORTWAV 154/8

Now, all of the above will work BUT there is one MAJOR problem.  It turns
out that while each GroupMail bundle has a unique filename, two or more
GroupMail bundles for the same conference can contain .PKT files that have
exactly the SAME names.  Thus, there is a very good chance that the above
batch file segment would fail whenever more than one mail bundle is
received for the SAME GroupMail area in the same transmission (it would
most likely stop and ask the user whether to overwrite the the .PKT file
from the first mail bundle with the .PKT file from the second... or on some
systems, it might just go ahead and overwrite the file without asking, an
even less desirable situation!).  On an MSDOS machine, you could use a FOR-
DO loop in the batch file to unarc each GroupMail bundle and then have
ConfMail toss (import) the contents of that mail bundle before unarcing and
tossing the next GroupMail bundle (but then, on an MSDOS machine you could
just run the GroupMail software).  There are probably ways to accomplish
the same thing on other systems, but the actual method would depend on the
commands available in the batch file language, and/or the availability of
external utilities that might aid in the process.  Or, you could just run
the batch file manually (when an operator is present to watch and resolve
any such conflicts that might occur)... that might be the most expiditious
method at present for point system operators.  Note to the developers of
GroupMail:  It would sure be nice if future versions did not create
duplicate .PKT names within different mail bundles for the same GroupMail
conference.

The method I've shown for preventing the imported GroupMail messages from
being rescanned back to the GroupMail feed is not real elegant, and begs
for a simple utility that would either a) reset the "high water mark" (the
number of the last message scanned by ConfMail Export) to that of the
highest message in the area, or b) append an Origin line and SEEN-BY lines
to any messages that don't already have them in the specified area, and
place the net/node number of the feed for the area in all messages
currently in that area.  Such a utility could be run every time messages
have been tossed to the specified area, and would eliminate the need for
the dummy ConfMail Export operation.  Yet another (better) option would be
to forget the alternate AREAS.BBS file and the dummy ConfMail Export
option, but instead use only the regular AREAS.BBS file with NO net/node
number following the Group conference area names, so that messages in Group
areas would NEVER be exported by ConfMail.  Then use a separate utility
that would search through Group conference areas for locally-originated
messages (messages containing the node's primary net/node number in the
FROM field of the message header) and move those TO the netmail area, at
the same time readdressing them to the feed for the GroupMail conference
and flagging them as Kill/Sent.  Such a utility would be relatively easy to
create, and would allow non-MSDOS systems to handle GroupMail in a way that
more closely resembles the way GroupMail is supposed to operate (that is, a
locally-entered message disappears from your BBS until such time as it
comes back as part of a GroupMail packet).

But, at this point, the fact that a non-MSDOS system can import and process
GroupMail is a bit akin to the dancing bear... the wonder is not how well
it's done, but that it can be done at all.

I hope that these hints prove helpful to you in setting up GroupMail on
BinkleyTerm/ConfMail and other types of systems.  Please let me know if you
find any glaring errors in the above information, or if you can add
anything that might simplify the process or make it more understandable.